<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
	<meta title="template local_template.html">
	<title>More interpreters</title>
	
</head>

<body>

<div id="main_title">More Interpreters</div>
<div id="content">
<p>In addition to the two interpreters (Borg and isolated) that we encountered
in the basic tutorials, Crunchy has a few more.</p>
<h3 >The <small>[dead]</small> parrot interpreter</h3>

<blockquote>
<em>
     <b>Mr. Praline:</b> ... I wish to complain about this parrot that I purchased not half an hour ago from this very boutique.<br/><br/>

     <b>Owner:</b> Oh yes, the, uh, the Norwegian Blue...What's, uh...What's wrong with it?<br/><br/>

     <b>Mr. Praline:</b> I'll tell you what's wrong with it, my lad. 'E's dead, that's what's wrong with it!<br/><br/>
     <b>Owner:</b> No, no, 'e's uh,...he's resting.<br/><br/>
</em>
<small>From Monty Python: the dead parrot sketch.</small>
</blockquote>

<p>The dead parrot sketch is a very funny, and very popular, sketch performed by Monty Python.  If you have never seen it, I encourage you to search for it on video.</p>
<p><em><b>What does this have to do with interpreters, you ask?</b></em> On the Python 
edu-sig list, Michael Tobis posted the following:</p>
<blockquote><em>
One problem I have consistently had with beginners is in explaining
the difference between how the interpreter produces output without an
explicit 'print' statement (producing the str() of the last evaluated
expression) and how python run from a file does not.<br/><br/>

This is perfectly natural and useful for an experienced user, but it
is awkward and confusing for the beginner, who has enough of a
cognitive load just trying to track all the pieces.<br/><br/>

This leads to two (well, four) questions:<br/><br/>

1) How have you folks addressed this problem in your beginning
classes? Do you find it causes difficulties?<br/><br/>

2) Would it be difficult to provide an alternative interpreter that
produced nothing unless you asked it to print? Would this be a good
idea?
</em>
</blockquote>
<p>These are very good questions that follow an insightful observation.
I will not attempt to answer them here, except to say that Crunchy addresses the third one [that is to say, the first one of the two that are
labeled as the second one] by providing not one, but two <small>[dead]</small> parrot interpreters.  These <small>[dead]</small> parrot interpreters
do not echo back what is typed into them; you need to explicitly type 
<code title="py_code">print</code> to get an output, as follows.</p>
<pre title="parrot">
>>> "'E's dead."
>>> print("He's resting.")
He's resting.
</pre>

<p>This <small>[dead]</small> parrot interpreter is unique; it behaves like an
individual interpreter encountered before.</p>

<h3 >The <small>[dead]</small> Parrots interpreter</h3>

<div class="notes">
<h4>Different prompts :-)</h4>
<p> The prompt <code class = "gp">_u__)</code> for the parrot interpreter
is meant to look like a <small>[dead]</small> parrot lying on its back, with its 
two legs pointing up as well as its long beak.  The <small>[dead]</small>
Parrots prompt is meant to represent many (two actually) <small>[dead]</small>
parrots, with only the beak from the second one showing, as it is hidden behind
the first.
</p>
</div>

<p>There can never be enough of a good thing - at least, I think so when it
comes to Crunchy.  This is why I give you the <small>[dead]</small> Parrots 
<small>[with a capital P and an 's' at the end]</small> interpreter.</p>

<pre title="Parrots">
>>> "'E's dead."
>>> print("He's resting.")
He's resting.
</pre>
<p>Like the Borg interpreter
these share all the same state.  They have been assimilated. 
You can confirm this by defining a variable in it, and verifying that it
is known by the other Borg interpreters on this page.</p>

<h3 >The TypeInfoConsole</h3>
<p>As a follow-up to Michael Tobis original post on edu-sig mentioned above,
John Posner suggested:</p>
<blockquote><i>... if the user types an expression that
returns a value,
have IDLE echo the return value <b>annotated with its type</b>, and with 
"&lt;&lt;&lt;" as a
prefix. Reversing the direction of the angle brackets is a neat (IMHO) way
to remind the user of the concept of "return value".
</i></blockquote>
<p>While we did not quite follow to the letter John's suggestion, we have
made available the TypeInfoConsole which you can try below.</p>
<pre title="TypeInfoConsole">
>>> a = 3   # assignment does not echo anything as usual
>>> a       # try and see for yourself what happens now
>>> fun = (1, 'a', {'a':1}, (1, 2), [1, 2], set('abc'), 1.0, 1+1j)
>>> for f in fun:
...     f
...
</pre>
<p>The TypeInfoConsole is another Borg-type interpreter.</p>

</div>

</body>
</html>
